Aminet 1

home *** CD-ROM | disk | FTP | other *** search

/ Aminet 1 / Aminet - June 1993 [Walnut Creek].iso / ab20 / datacomm / serservr.lzh / SerServer.doc < prev next >

Wrap

Text File | 1990-05-01 | 15.3 KB | 374 lines

*************************************************************************** * * * SerServer & Con1-Handler * * * * All parts (c) Copyright 1990 by Michael R. Mossman. * * * * Released for private, non-commercial use. * * * * Compiled with Lattice 5.04. * * * *************************************************************************** SerServer - Version 1.03 What is it? Maybe a better name would have been CliBBS, but I started with SerServer and so it will stay. It is a personal (with the lack of a better word) BBS program. It gives the user a full CLI with restrictions setup by the sysop. I don't like the word BBS in this case, because, any program that offers a CLI to strangers, can be a lot of trouble. I wrote the program so that I can log on to my computer from work and do all of the things that I do from home in a CLI. I do not recommend that you let any Tom, Dick or Harry in to use this program. You will end up with formatted hard drives and sleepless nights. It has three user levels, and full Zmodem UP/DOWNLOAD. It could be a very useful program for a few friends and your self to use, when working on a common project. A place to share files. It offers limited message sending and receiving. What files are in the zoo? Con1-Handler - this is the DOS handler for the CLI. SerServer - this is the serial device interface and it talks to Con1-Handler. SySop - This program configures the "BBS" and maintains the user/password list. help - This is just a text file that you edit, to tell users what commands and devices, are available to them. logon - Another text file that the user gets before they enter their name and password. greeting - Another text file that the user gets after login. mountlist - This shows how to enter the Con1-Handler in your mountlist. Zmodem.zoo - This zoo contains sz and rz. The two public domain external protocols Zmodem handlers. Sz is the upload handler and rz receives the files. NoRequests.zoo - This public domain program prevents requesters from coming up when the user asks for a disk or a drive that is not present in the system. You can't click off a requester when your sitting at a remote terminal! SerServer calls this program when it firsts starts up. Setting it up! First off make a mountlist entry for the Con1-Handler. Make a directory somewhere called "bbs". Then assign it, eg - "assign bbs: device:subdirectory/bbs". Create a subdirectory off of bbs: and call it "mail". Next sit down with a pen and paper and think. Write down all the devices that are available to level 1 users (the lowest level). Think very carefully about what devices you select. (I try to keep people off my hard drive.) Then select the commands that level 1 users can execute. (Format seems to be a bad choice.) Commands that open their own window, should not be used because most of them will not return control to the CLI and the remote user can not close the window. Do the same thing for level 2 users. You might ask, why two levels? I find that I can trust some people more then others. You might loan your Corvette to some friends and the Volkeswagon to others. There must be one device that is common to all level users. This is called the "HOME DIRECTORY DEVICE". The root of this device is where all level of users will start from when they log on. It is also the area that all uploads and downloads take place. A file must be moved here, before it can be sent. Received files will arrive here. Do not use Ram: as your "HOME DIRECTORY DEVICE". Rz checks how much space is left on Ram: before it receives a download file. Ram: then says that it has 0 blocks free and rz aborts the transfer. Decide what level can download from your system. Decide what level can upload to your computer (this is much more dangerous then downloading and should require a higher level). If you select a level of 4 for up/downloading then no level user will be able to send or receive files. The modem string has to be just right for this program to work. I use ATE0 L0 M1 Q0 V1 &D2 on a Supra 2400. I will explain each entry in case your modem is not a Supra. E0 - Modem does not echo back commands (this is important. L0 - Low speaker volume (does not matter). M1 - Speaker on until carrier received (does not matter). Q0 - Modem returns result codes after commands (this is important). V1 - Selects Verbal result codes (this is important). &D2 - Modem hangs up, disables autoanswer, and goes to command state upon ON-to-OFF transition of DTR line (this is important). DO NOT PUT THE MODEM IN THE AUTOANSWER MODE eg. ATS0=1. Now execute Sysop and select "Configure". It will put a file in the assigned BBS: subdirectory called config. Enter the previous well thought out data. Now move SerServer, Sysop, NoRequest, logon, help and greeting into the assigned BBS: subdirectory (the text files help, greeting and logon, do not have to be present for SerServer to work). Copy sz and rz into the C: subdirectory. Copy Con1-Handler into the L: subdirectory. The DOS commands copy, cd and endcli, must be in the C: subdirectory. Use Sysop to enter yourself and who ever, in the userlist. This will create a file called passwords in the assigned BBS: subdirectory. Make sure that the sysop is the first entry in the password file and remember the password. You will be asked for this password every time you run this program to make changes. The program does this to prevent someone from uploading the file to the BBS and making changes to the config or passwords. The program also writes to the log if you fail the password. Now do the following: mount con1: (done after a reboot and not yet mounted) assign bbs: device:subdirectory/bbs (after a reboot) newcli con1: (every time the program is started) SerServer (every time the program is started) Now the program is up and running and ready for someone to logon. The text that is received from the Con1-Handler and the serial device is send to the CLI window that serserver is started up from. The program can be terminated by selecting the CLI window and typing Control C. People logging on should set their terminal programs for 8N1. Commands SerServer will parse the command line for level 1 and 2 users. If a user types "df0:dir" then the parser will eliminate the "df0:" and only "dir" will be sent to CLI (this assumes that dir is an allowed command). This along with alias (as shown later) will prevent users from renaming files (to an allowed command name) and then uploading and executing them. Commands that should not be allowed to level 1 and 2 users are execute, alias, assign, protect, endcli and format. Help A user can type help or "?" along the command line and get a help file if the Sysop provides a text file called "help". Mail At a CLI prompt a user can type "mail" and they can leave private or public mail. Private mail is created in a file under the users name (the name of the user who is to receive the mail). Private mail will be deleated after it is read by the user. Public mail is put in a file called "ALL". It will grow in size until the sysop either deletes it or edits it. (Some text editors can handle this file.) All messages are saved in "bbs:mail/". Things to think about! Level 3 is the highest level user. There is no parsing of the command line for a level 3 user. If format is in the command path and a level 3 user says "format drive DH0: name NOTHING" then your brand new hard drive will erase it's brains. The same thing can happen with any level user, if you make the command available to them. If you make Alias available as a command then users can do things like "alias dir format" and type "dir drive DH0: name NOTHING" and format your hard drive if DH0: is one of the available devices and dir is an allowed command. How about if you make zoo an available command and a user puts format renamed as dir in the zoo. They can then de-zoo the file and format your hard drive because the CLI will find dir command in the current path (really format) before it goes to c:. Endcli will terminate SerServer from a remote. I felt that this was handy for the sysop to drop the program from a remote terminal but can be a problem, if it is an allowed command. What I'm trying to say is, pick your commands and devices carefully. And most important, know who the hell your letting on your computer! Timings and Stuff Anyone is allowed one minute to type in their name at the login prompt, another minute for the password. Everyone is allowed three tries and then it hangs up. Level 1 and level 2 users are allowed two minutes of inactivity at a CLI prompt before the program drops them. Level 3 users can be at a CLI all day and do nothing and the program will not hang up. In the Mail section of the program, time outs will happen to any level user. There is no limit to the over all on time for any level user as long as they are doing something. Log Keeping The program keeps a log in the BBS: subdirectory called "log'. This requires that BBS disk NOT be write protected. Zmodem Stuff The program uses Zmodem for up/downloads. Sending from a remote is easy. I used Online!, Telix and JrComm for testing. Just select 32 bit CRC (16 bit works also) and at a CLI prompt in the BBS, select upload in Online!, JrComm, or Telix. Pick the files and then sit back and wait (have a beer) till they all arrive at the BBS. Sending files requires a little more work. First the files have to be in the "HOME DIRECTORY DEVICE" root. Use copy to move them there. Then along the CLI prompt line type: send file1 file2 file3 (etc) Make sure your terminal program is setup for auto downloads. "Send" will also accept several options, like so: send -ao file1 file2 The options are these: + - append to existing file. a - (ascii) change NL to CR/LF in text file. b - binary file transfer. e - escape all control characters. n - send file if source is newer. N - send file if source is newer or longer. o - use 16 bit CRC checking. p - protect existing destination file. r - resume/recover interrupted file transfer. y - overwrite existing file. Not all of the options of sz are supported in SerServer, and it will prevent unsupported options from being used. Neet Things There are some neet things that you can do with Alias. It can provide a whole bunch of extra commands this way. Say you want users to be able to read the log file but don't want them to have access to Df0: where the bbs: files are kept. You can then set up an Alias that reads like this: Alias log type bbs:log You then add log as a command to the Sysop program, and users can read the log file. Say you have a bunch of users that don't know dos commands. You can add help files for each allowed command by doing somthing like this. Create a subdirectory off bbs: called "help". Then put a text file in there called "dir". This text file will explain the "Dir" command and it's options. Then set up an Alias like this: Alias what type bbs:help/[] The user then types "what dir" and gets a help file on "Dir". What has to be added to the allowed commands. Scripts Here are a couple example scripts to show you how to set up the the BBS and use the alias command. assign bbs: df0:bbs c:mount con1: newshell con1: from s:remote-shell <---- This starts the remote-shell script. stack 10000 bbs:serserver endcli And here is the remote-shell script. stack 10000 cd vd0: Prompt "(%N) %S>> alias dir c:dir <---- You should have an entry like these alias list c:list for every allowed command for alias type c:type Level 1 & 2 users. This helps prevent alias echo c:echo <---- users uploading and executing a file. alias copy copy [] NOPRO BUF=10 <---- allows copyied protected files to be deleted. alias log type bbs:log <---- Gives the log to users. alias what type bbs:help/[] <---- If you want help files. Bugs and Other Critters of the Night Well this is version 1.03, so what can I say. People doing buffer dumps and hanging up in the middle of things can always be a problem. I have tried to catch these problems, but bugs always seem to surface. I am releasing the executable but will retain the source on this one. Let me know if you find any problems. Please don't say it just locked up, try to tell me what the program was doing, when it locked up! Things to Do Programs like this always have things that can be added. I might add a chat feature in the future. But for now, this meets my needs. I program for me first and you last. CopyRight and Things I am retaining the copyright on Con1-Handler and SerServer Version 1.03 but will release it's use to the public for non-commercial use. How To Rip Me Apart You can contact me on CompuServe, my UI is 76515,3017. You can also reach me on Fido Net 1:255/1 or Punter Net Node 95. Thanks Many thanks to Wayne Marchand and the Mad Scientist for debugging and helpful comments. A real big thanks goes out to Mad for pulling down his bbs and putting up SerServer. This found bugs, that would have taken years to find by using a term prog on my 500 and SerServer installed on my 2500. History Version 1.00 - Orginal alpha testing version. Not released to public. Version 1.01 - Fixed bug in dropped carrier lockup. Program was waiting on timer message that never came. Fixed PassWordMaker so that it did not wreck the password file when editing user entries. Not released to public. Version 1.02 - Added log keeping and moved sz & rz into the C: subdirectory from the "HOME DIRECTORY". Not released to the public. Version 1.03 - PassWordMaker was rewritten by The Mad Scientist and called Sysop. Thanks a lot Doug! (call his BBS at 506-648-9196). Added the mail feature and caught a few more bugs. Added Mail to the Sysop program so the sysop can read his own mail (or anyone's). Made level 1 and 2 users command line get parsed so a path can not be set to a command. Password protected the Sysop file.